線上儀表板可以看起來很健康，與此同時客戶正默默地過著糟糕的體驗。如果我只收集使用者自願提交的回饋，我看到的大多是有動力抱怨的人。那些放棄對話的使用者、因第一個答案不清楚而重複發問的使用者，或在沒有察覺的情況下接受了錯誤回應的使用者，可能永遠不會出現在回饋資料裡。我能看到什麼，取決於我怎麼收集證據，而不是系統產生多少資料。

作為 QA 工程師，我需要回答關於線上監控的三個問題：哪些訊號能揭示行為的變化、我需要檢視多少資料，以及一個線上失敗什麼時候值得進入固定的黃金集。

這對 AI 功能尤其重要，因為自動化指標可以顯示「某件事變了」，卻無法解釋回應是否真的變糟了。延遲飆升是可量測的，但要判斷助手是否錯誤陳述了一項退貨政策，可能需要拿整段對話對照既定的評分標準（rubric）來讀。因此，我的抽樣設計本身就是品質策略的一部分。如果選得不好，儀表板可以給我一張令人信服——但不完整——的線上品質圖像。

1. 抽樣方法決定你看到什麼

我把線上觀察組織成三層。第一層是自動、全量的監控：延遲、成本、錯誤率、逾時率、轉人工率等訊號，從所有符合條件的互動中收集。這些量測不需要有人逐則對話去讀，但它們的趨勢必須隨時間可見。如果 Aurora Shop 的助手突然要多花一倍的時間才回答，我想要在不等客戶回報的情況下就偵測到這個變化。全量監控有助於辨認行為什麼時候、在哪裡發生位移，即使它不一定能解釋為什麼。

第二層是隨機抽樣：每天隨機選取固定數量的對話，由人依照既定的品質評分標準來評分。例如，一個團隊可以每天審看 100 則隨機選出的對話作為初期的演練目標，再依流量、風險與審看者的人力來調整這個數字。隨機抽樣讓相對安靜的互動也有機會被檢視，而不是任由投訴決定整個樣本。

第三層是刻意抽樣，它有針對性地指向比較可能藏著重要失敗的區域：退款、庫存、促銷這類高風險意圖；異常長的對話；以及成本最高的前 1% 對話。這三層的目的各自不同：隨機抽樣幫助估計整體品質，刻意抽樣則是為了狩獵特定風險。使用者回饋仍然有價值，但它是一條調查的線索——不是估算整體品質的分母。

2. 線上品質訊號需要清楚的定義

每一個線上指標都需要把分子與分母寫下來。否則，一個數字可以被拗成任何講的人想要的意義。例如，Aurora Shop 的使用者回報率，就是由使用者回報的對話數，除以對話總數。如果 10,000 則對話中有 40 則被回報，比率是 0.4%。這個數字不能證明其餘 99.6% 都是好對話；它只告訴我使用者提交回報的頻率。很多使用者從不回報問題，而有些人可能根本沒察覺答案錯了。

其他訊號揭示的是不同種類的摩擦。重複提問率（re-ask rate）量測的是：在一段定義好的短時間窗內，針對同一意圖的重複提問次數，除以涉及該意圖的對話數。一位客戶三次詢問退貨政策，可能表示第一個回答不清楚、不完整，或自相矛盾。轉人工率（handoff rate）量測的是轉給真人的對話數除以對話總數。它的突然上升，可能代表助手在掙扎，但也可能反映真實流量的變化，或一次刻意的路由政策調整。這些指標都是線索，不是自動診斷。它們的定義、觀察時間窗與隨時間的變化，需要與抽樣的對話一起解讀，QA 才能下結論說某個缺陷存在。

3. 壞案例必須小心地回流到黃金集

當線上監控能改善未來的測試時，它的價值才真正放大。當一則被抽樣的對話暴露出一個有意義的失敗，我會想要保存這個案例，讓同樣的行為在未來的 prompt 與模型版本上都能被檢查。例如，如果 Aurora Shop 的助手在核准政策只允許 14 天的情況下反覆捏造 30 天退貨期限，這個已確認的失敗可以成為一個黃金集案例，附上相關上下文、預期屬性、禁止事項，以及可重現的評估程序。這樣一來，缺陷就不會在某位同事處理完那位個別客戶之後，就消失在一張支援單裡。

不過，有兩種污染需要注意。第一，同一則對話可能被回報多次，或同一個底層失敗可能出現在好幾則幾乎相同的對話中。把每一筆重複都當成獨立案例計算，會扭曲量測到的通過率，讓一次事件看起來像是許多獨立的失敗。案例因此應該被去除重複，或連結到同一個共享事件，同時保留關於頻率的有用資訊。

第二，原始的線上對話可能包含姓名、訂單號碼、聯絡方式或其他敏感資訊。把它們直接複製進一個長期存在的黃金集，會造成不必要的隱私與留存風險。原則是資料最小化：只保留判斷行為所需要的欄位，在適當處移除或雜湊識別資訊，並記錄資料允許保留多久。一個線上失敗應該變成可重用的測試證據，而不是把評估集變成一個不受控的客戶對話檔案庫。

線上觀察規格

這張表把監控策略具體化，將每一個訊號連結到抽樣方式、審查頻率，與壞案例的回饋流程。使用者回報率、重複提問率與轉人工率，都自動跨全量互動監控、每日審看。人工評分的壞案例率使用隨機抽樣，讓團隊得以檢視會抱怨的使用者之外的整體品質。延遲與成本每小時監控，異常時間窗會觸發刻意抽樣；安全事件則依指定流程接受即時偵測與 100% 人工審查。最後一欄解釋訊號出現之後發生什麼：回報被打上意圖與標籤並經確認、重複提問被送去審查、抽樣發現的失敗經評分去重後進入黃金集、安全事件變成強制測試案例。關鍵的想法是：監控不會在指標變化時就結束；它需要一條被定義好的路徑，從訊號，到調查，到可重用的證據。

樣本能揭示問題存在，卻說不出全貌

這份規格有兩個結構上的限制。第一，抽樣只檢視互動的一個子集：它可以幫助揭示問題存在，卻無法自動建立問題有多大。壞案例間的嚴重度差異很大，而平均值會把長尾埋掉。第二，把線上失敗回灌黃金集，會讓那個集合逐漸偏向線上的分布，而隨著已知案例被修掉或被過度代表，它的通過率可能一路漂高。如果沒有一個凍結的對照集，我無法可靠地分辨：系統真的變好了，還是只是題目變簡單了。

還有一個實務上的限制：讀樣本需要時間，而最有能力判斷客服答案好壞的人，往往正是忙著回工單的那些人。審看者的時間必須被明確地編列預算，否則樣本只會堆積著沒人讀，觀察規格最後淪為裝飾。線上監控只有在抽樣是刻意的、證據有人審、發現回流到測試而不悄悄扭曲進度量尺的時候，才真正有用。